Wow. This PR removes aria-label and aria-labelledby from all of the following roles:

• alert
• blockquote
• caption
• cell
• definition
• deletion
• heading
• insertion
• label
• legend
• listitem
• log
• marquee
• math
• note
• paragraph
• presentation
• roletype
• rowgroup
• section
• sectionhead
• status
• structure
• subscript
• superscript
• term
• time
• timer
• tooltip

That's a lot of roles. :)

At first glance, I'm wondering about heading, because @DavidMacDonald's testing of aria-label, etc on static elements says:

If its a heading role , aria-label or aria-labelledby overrides it on NVDA, VoiceOver and Talkback. JAWS ignores the aria-label or aria-labelledby.

So we would break some expectations. Not sure of actual use in the wild.
Would sure be nice to have that data.

This is a Draft PR. Its purpose is to provoke discussion. It is not going to be merged as-is.

No worries. My comment was supposed to be the beginning of the discussion. :)
Edited to remove "before we commit this PR", so the final sentence now reads "Would sure be nice to have that data.", because that's all I really meant.

Not sure if we should remove aria-label/aria-labelledby from math role?
Here's some discussion on labelling math role from @AmeliaBR and @joanmarie

Hi,
Just for the record, I wanted to document my concerns that I brought up during the meeting, and to expound on some primary concerns about the proposal here.

First, here is a basic example of a standard visual technique that is used all across the web to represent pagination buttons, itemized shopping cart buttons, new message buttons, date picker next and previous month and year buttons, and many other types.

<button><span aria-label="Next " class="nextArrowIcon"></span>Email</button>

This, plus the prevention of labeling on generic roles, will break all such implementations everywhere.

Regarding the points I made about the AccName and ARIA specs, it will be a very bad idea to say that these attributes will remain valid regardless of role within the AccName spec, but that the same attributes are prohibited in the ARIA spec on specific roles.

As was mentioned, I could indeed say that certain uses are valid when traversing child nodes within the AccName spec, however these will still be documented as prohibited in the ARIA spec with no such exceptions, thus leading to the same contradictions between the two normative specs.

If the purpose that we are trying to solve here is to prevent authors from being stupid, there is nothing that will ever prevent people from doing stupid things. As John Cleese said once: "You can't fix stupid."

However, if the intent is to get validators to flag improper uses of ARIA, this is best solved by adding these combinations to the HTML-ARIA spec because this is what the HTML validator actually maps to directly, and not the ARIA spec where such implementations might be the only way to fix specific accessibility issues when encountered. This is very important when remediating enterprise CMS platforms with legacy code bases.

There is another ramification when separating out a bunch of valid versus invalid roles when computing the accessible name, which will likely have an impact on the process speed and efficiency of the naming computation itself within browsers. If every iteration of the algorithm has to check every node against a comprehensive list of valid versus invalid role and element combinations, and this must be done on everything on the page to compute accessible names for everything, it will likely cause some pretty significant process lags and performance hits. This will already need to be done to a minor extent for roles that support name from content as opposed to those that don't when processing child nodes as we've previously discussed, but checking against a total index of all possible roles and implicit element types on every node during this traversal process will be expensive.

With all of these considerations in mind, I recommend leaving these attributes as global, and simply add recommended usage patterns to the HTML-ARIA spec instead to guide user authoring practices that way, rather than by messing with the actual accessibility of elements at their fundamental levels by breaking present day solutions that are already accessible.

All the best,
Bryan

I'd like to echo @accdc's concern about any change to ARIA that would be a breaking change in the wild. I hope the ARIA Working Group will carefully consider the impact of any potential breaking changes to the ARIA spec; there seems to be considerable danger that web developers who are not well versed in the intricacies of ARIA, and for whom it took considerable effort to persuade them to adopt the additional markup in their pages, will throw their hands up and abandon ARIA if non-backward compatible changes are introduced into the markup specification.

In particular, developers often use frameworks such as Modernizr to allow them to support a wide range of browsers, versions, and platforms that are part of the business requirements; however, it is impossible for these frameworks to detect which version of assistive technology (especially screen reader) is being used, so it is not possible for web pages to modify their behavior to adapt to older and newer versions of AT. This would make any breaking changes in ARIA especially impactful.

Also echoing @accdc's concerns and wanted to highlight that I also agree that the following is the best way to begin steering devs and authors away from unintended usage:

"...this is best solved by adding these combinations to the HTML-ARIA spec because this is what the HTML validator actually maps to directly, and not the ARIA spec where such implementations might be the only way to fix specific accessibility issues when encountered."

Validation should be the carrot that leads folks away from improper usage, rather than breaking changes being introduced to the spec.

Decided yet again not to go this way. closing